Limiting the execution of background management operations in a drive array

ABSTRACT

Limiting the execution of background management operations in a drive array, including: receiving a read instruction to read data from a memory drive in the drive array; determining whether the read instruction is associated with a write instruction to write data to a memory drive in the drive array; responsive to determining that the read instruction is associated with the write instruction, restricting performance of background management operations on the memory drive targeted by the write instruction; determining whether the write instruction has completed; and responsive to determining that the write instruction has completed, removing restrictions associated with the performance of background management operations on the memory drive targeted by the write instruction.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The field of the invention is data processing, or, more specifically,methods, apparatus, and products for limiting the execution ofbackground management operations in a drive array.

2. Description of Related Art

Storage systems can be embodied as a redundant array of independentdisks (‘RAID’) that are controlled by a RAID controller. RAIDcontrollers protect data by adding parity protection over a group ofindependent storage devices. Parity calculations require the RAIDcontroller to use a number of reads and writes that are in some casesdependent on one another to keep the drive group coherent. The paritycalculations on a RAID array require data from multiple sources andwrites will have to wait for a series of reads and these paritycalculations to complete. Individual devices can interpret the pause inactivity as an opportunity to perform background tasks such as datascrubbing or consistency checking, which can hurt write performance onthe storage array.

SUMMARY OF THE INVENTION

Methods, apparatus, and products for limiting the execution ofbackground management operations in a drive array, including: receiving,by a drive array controller, a read instruction to read data from amemory drive in the drive array; determining, by the drive arraycontroller, whether the read instruction is associated with a writeinstruction to write data to a memory drive in the drive array;responsive to determining, by the drive array controller, that the readinstruction is associated with the write instruction, restricting, bythe drive array controller, performance of background managementoperations on the memory drive targeted by the write instruction;determining, by the drive array controller, whether the writeinstruction has completed; and responsive to determining, by the drivearray controller, that the write instruction has completed, removing, bythe drive array controller, restrictions associated with the performanceof background management operations on the memory drive targeted by thewrite instruction.

The foregoing and other objects, features and advantages of theinvention will be apparent from the following more particulardescriptions of example embodiments of the invention as illustrated inthe accompanying drawings wherein like reference numbers generallyrepresent like parts of example embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 sets forth a block diagram of automated computing machinerycomprising an example computer useful in limiting the execution ofbackground management operations in a drive array according toembodiments of the present invention.

FIG. 2 sets forth a flow chart illustrating an example method forlimiting the execution of background management operations in a drivearray according to embodiments of the present invention.

FIG. 3 sets forth a flow chart illustrating an additional example methodfor limiting the execution of background management operations in adrive array according to embodiments of the present invention.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Example methods, apparatus, and products for limiting the execution ofbackground management operations in a drive array in accordance with thepresent invention are described with reference to the accompanyingdrawings, beginning with FIG. 1. FIG. 1 sets forth a block diagram ofautomated computing machinery comprising an example computer (152)useful in limiting the execution of background management operations ina drive array according to embodiments of the present invention. Thecomputer (152) of FIG. 1 includes at least one computer processor (156)or ‘CPU’ as well as random access memory (168) (RAM') which is connectedthrough a high speed memory bus (166) and bus adapter (158) to processor(156) and to other components of the computer (152).

Stored in RAM (168) is an application program (126), a module ofuser-level computer program instructions for carrying out particulardata processing tasks on the computer (152). Examples of suchapplication programs include spreadsheets, word processing programs,email clients, web browsers, database management programs, and so on.Also stored in RAM is a drive controller interface (130), a module ofcomputer program instructions that provides an application programminginterface or ‘API’ through which the application program (126) cancommunicate with a drive array controller (204), such as a redundantarray of independent disks (‘RAID’) controller, for writing and readingdata to and from one or more memory drives (224, 226, 228) in a drivearray (222).

Also stored in RAM (168) is an operating system (154). Operating systemsuseful limiting the execution of background management operations in adrive array according to embodiments of the present invention includeUNIX^(TM), Linux^(TM), Microsoft XP™, AIX™, IBM's i5/OS™, and others aswill occur to those of skill in the art. The operating system (154),application program (126), and drive controller interface (130) in theexample of FIG. 1 are shown in RAM (168), but many components of suchsoftware typically are stored in non-volatile memory also, such as, forexample, on a memory drive.

The example computer (152) of FIG. 1 includes one or more input/output(‘I/O’) adapters (178). I/O adapters implement user-orientedinput/output through, for example, software drivers and computerhardware for controlling output to display devices such as computerdisplay screens, as well as user input from user input devices (181)such as keyboards and mice. The example computer (152) of FIG. 1includes a video adapter (209), which is an example of an I/O adapterspecially designed for graphic output to a display device (180) such asa display screen or computer monitor. Video adapter (209) is connectedto processor (156) through a high speed video bus (164), bus adapter(158), and the front side bus (162), which is also a high speed bus.

The example computer (152) of FIG. 1 includes a communications adapter(167) for data communications with other computers (182) and for datacommunications with a data communications network (100). Such datacommunications may be carried out serially through RS-232 connections,through external buses such as a Universal Serial Bus (‘USB’), throughdata communications networks such as IP data communications networks,and in other ways as will occur to those of skill in the art.Communications adapters implement the hardware level of datacommunications through which one computer sends data communications toanother computer, directly or through a data communications network.Examples of communications adapters useful for limiting the execution ofbackground management operations in a drive array according toembodiments of the present invention include modems for wired dial-upcommunications, Ethernet (IEEE 802.3) adapters for wired datacommunications network communications, and 802.11 adapters for wirelessdata communications network communications.

The example computer of FIG. 1 also includes a drive array controller(204) coupled through an expansion bus (160) and a bus adapter (158) toa processor (156) and other components of the computer (152). The drivearray controller (204) is a computer input/output adapter that connectsnon-volatile data storage to the computer (152) in the form of memorydrives (224, 226, 228). The drive array controller (204) of FIG. 1administers read and write requests to and from memory drives (224, 226,228).

In the example of FIG. 1, the drive array controller (204) can carry outlimiting the execution of background management operations in a drivearray (222) by receiving a read instruction to read data from a firstmemory drive (224) in a drive array (222). The read instruction may bereceived from the computer processor (156) that sends the readinstruction to the drive array controller (204) over a memory bus. Sucha read instruction may be part of a larger memory management operationsuch as, for example, performing parity calculations for memory drives(224, 226, 228) in the drive array (222).

In the example of FIG. 1, the drive array controller (204) can furthercarry out limiting the execution of background management operations ina drive array (222) by determining whether the read instruction isassociated with a write instruction to write data to a second memorydrive (226) in the drive array (222). Determining whether the readinstruction is associated with a write instruction to write data to asecond memory drive (226) in the drive array (222) may be carried out,for example, through the use of flags that are contained in the readinstruction (202), through the use of flags that are contained in thedata that is to be read as a result of the read instruction (202), andso on.

Consider an example in which the drive array (222) is a RAID 5 compliantarray. In such an example, performing parity calculations for the drivearray (222) can include reading data from a plurality of memory drives(224, 228), using the data that was read from the memory drives (224,228) as input to an exclusive OR operation, and subsequently writing theresult of the exclusive OR operation to another memory drive (226) thatis responsible for maintaining parity information for a particularportion of the memory drives (224, 228). In such an example, a readinstruction would be issued to memory drive (224) and another readinstruction would be issued to memory drive (228). Each read instructionwould be associated with a write instruction that will be issued tomemory drive (226) upon the completion of the exclusive OR operation. Assuch, even though memory drive (226) may not be actively servicing anymemory access requests, the issuance of a read instruction to memorydrive (224) and another read instruction to memory drive (228) as partof parity calculations would serve as an indication that memory drive(226) will be servicing a memory access request—writing the result ofthe exclusive OR operation to the memory drive (226)—in the near future.

In the example of FIG. 1, the drive array controller (204) can furthercarry out limiting the execution of background management operations ina drive array (222) by restricting performance of background managementoperations on the second memory drive (226) in the drive array (222).Restricting performance of background management operations on thesecond memory drive (226) in the drive array (222) is carried out inresponse to affirmatively determining that the read instruction isassociated with the write instruction. Background management operationscan include data scrubbing operations, consistency checking, and othermanagement operations that are frequently run as background tasks toensure proper operation of the memory drives (224, 226, 228). Aparticular operation may be identified as being a background managementoperation, for example, as part of configuring a computing system, asthe result of input from a system administrator, and so on. Suchbackground operations are typically executed through the use of abackground process that is running in the background without userintervention.

When a particular memory drive (224, 226, 228) is servicing memoryaccess requests that are performed as part of background managementoperations, the memory drive (224, 226, 228) will have less capacity toservice memory access requests that are performed as the result ofnormal computing operations. The memory drive (224, 226, 228) may haveless capacity to service memory access requests that are performed asthe result of normal computing operations because resources required toservice memory access requests that are performed as part of backgroundmanagement operations are being dedicated to the execution of thebackground management operations. As such, the performance of backgroundmanagement operations on the second memory drive (226) in the drivearray (222) may be restricted in anticipation of servicing the writeinstruction that is related to the read instruction. Restricting theperformance of background management operations on the second memorydrive (226) in the drive array (222) can include, for example, limitingthe percentage of memory access requests that the second memory drive(226) may service as part of performing background management operationsto a predetermined threshold.

In the example of FIG. 1, the drive array controller (204) can furthercarry out limiting the execution of background management operations ina drive array (222) by receiving the write instruction. The writeinstruction may be issued to the drive array controller (204), forexample, by the computer processor (156) over a memory bus. Such a writeinstruction may be part of a larger memory management operation such as,for example, performing parity calculations for memory drives (224, 226,228) in the drive array (222).

In the example of FIG. 1, the drive array controller (204) can furthercarry out limiting the execution of background management operations ina drive array (222) by determining whether the write instruction hascompleted. Determining whether the write instruction has completed maybe carried out, for example, by inspecting each completed writeinstruction that the drive array controller (204) causes to execute. Insuch an example, each completed write instruction may be examined todetermine whether the executed write instruction is the same writeinstruction that is related to the read instruction. In order todetermine whether a particular executed write instruction is the samewrite instruction that is related to the read instruction, the readinstruction and the write instruction may include metadata thatidentifies the two instructions as being related. Such metadata mayinclude, for example, an identifier that includes a unique value that isincluded in metadata associated with the read instruction and alsoincluded in metadata associated with the write instruction. In such anexample, when the drive array controller (204) receives a readinstruction that has a related write instruction, the drive arraycontroller (204) may store the unique identifier contained in the readinstruction. This value may be compared against values contained inmetadata associated with incoming write instructions to identify thewrite instruction that includes a matching unique identifier.

Consider the example described above in which the drive array (222) is aRAID 5 compliant array. Performing parity calculations for the drivearray (222) can therefore include reading data from a plurality ofmemory drives (224, 228), using the data that was read from the memorydrives (224, 228) as input to an exclusive OR operation, andsubsequently writing the result of the exclusive OR operation to anothermemory drive (226) that is responsible for maintaining parityinformation for a particular portion of the memory drives (224, 228). Insuch an example, the read instruction that is issued to memory drive(224) and read instruction that is issued to memory drive (228) mayinclude metadata identifying these read instructions as being related toa write instruction that has not yet been issued. Each read instructioncan also include a particular value that is to be used as an identifierof the group of instructions. This value can be stored in memory used bythe drive array controller (204). When the drive array controller (204)subsequently receives an incoming write instruction, the drive arraycontroller (204) may examine the metadata associated with the incomingwrite instruction to determine whether the metadata associated with theincoming write instruction includes a value that matches the value thatwas that includes in the read instruction that is issued to memory drive(224) and read instruction that is issued to memory drive (228). If thevalues match, the incoming write instruction represents that relatedwrite instruction that was identified in the read instruction that isissued to memory drive (224) and read instruction that is issued tomemory drive (228). Once the related write instruction is executed,there is no longer a need to restrict the performance of backgroundmanagement operations on the memory drive (226) targeted by the writeoperation.

In the example of FIG. 1, the drive array controller (204) can furthercarry out limiting the execution of background management operations ina drive array (222) by removing the restrictions associated with theperformance of background management operations on the second memorydrive (226) in the drive array (222). Removing the restrictionsassociated with the performance of background management operations onthe second memory drive (226) in the drive array (222) is carried out inresponse to affirmatively determining that the write instruction hascompleted. Removing the restrictions associated with the performance ofbackground management operations on the second memory drive (226) in thedrive array (222) may be carried out, for example, by removing anylimitations as to the percentage of memory access requests that thesecond memory drive (226) may service as part of performing backgroundmanagement operations, by increasing the percentage of memory accessrequests that the second memory drive (226) may service as part ofperforming background management operations, and so on.

For further explanation, FIG. 2 sets forth a flow chart illustrating anexample method for limiting the execution of background managementoperations in a drive array (222) according to embodiments of thepresent invention. The drive array (222) of FIG. 2 includes a pluralityof memory drives (224, 226, 228). Each memory drive (224, 226, 228) maybe embodied as a distinct computer storage device such as, for example,a disk drive, a solid state drive, and so on. The memory drives (224,226, 228) are pooled together to create a drive array (222) which is astorage system that contains multiple memory drives to provide increasedavailability and resiliency through the use of redundant components. Thedrive array (222) of FIG. 2 may be embodied, for example, as a redundantarray of independent disks (‘RAID’). Such a RAID may adhere to standardRAID levels such as RAID 5 in which parity and data are distributedamongst the memory drives (224, 226, 228).

The example method of FIG. 2 is carried out by a drive array controller(204). The drive array controller (204) of FIG. 2 may be embodied as adevice to manage the drive array (222), including the memory drives(224, 226, 228) that form the drive array (222). For example, the drivearray controller (204) of FIG. 2 may be embodied as a RAID controllerwhich manages the physical memory drives (224, 226, 228) of a RAID andpresents them to a computing device as logical units.

The example method of FIG. 2 includes receiving (206), by the drivearray controller (204), a read instruction (202) to read data from afirst memory drive (224) in a drive array (222). In the example methodof FIG. 2, the read instruction (202) may be received from a computerprocessor (not shown) that sends the read instruction (202) to the drivearray controller (204) over a memory bus. Such a read instruction (202)may be part of a larger memory management operation such as, forexample, performing parity calculations for memory drives (224, 226,228) in the drive array (222).

The example method of FIG. 2 also includes determining (208), by thedrive array controller (204), whether the read instruction (202) isassociated with a write instruction (200) to write data to a secondmemory drive (226) in the drive array (222). In the example method ofFIG. 2, determining (208) whether the read instruction (202) isassociated with a write instruction (200) to write data to a secondmemory drive (226) in the drive array (222) may be carried out, forexample, through the use of flags that are contained in the readinstruction (202), through the use of flags that are contained in thedata that is to be read as a result of the read instruction (202), andso on. For example, the read instruction (202) may include metadata thatis associated with the read instruction (202). Such metadata mayinclude, for example, an integer value that is set by the issuer of theread instruction (202) to identify whether the read instruction (202) isassociated with a write instruction (200) to write data to a secondmemory drive (226) in the drive array (222). A value of 0 may indicatethat the read instruction (202) is not associated with a writeinstruction (200) to write data to a second memory drive (226) in thedrive array (222), while a value of 1 may indicate that the readinstruction (202) is associated with a write instruction (200) to writedata to a second memory drive (226) in the drive array (222). In such anexample, the drive array controller (204) may read the values containedin such flags to determine (208) whether the read instruction (202) isassociated with a write instruction (200) to write data to a secondmemory drive (226) in the drive array (222).

Readers will appreciate in the example method of FIG. 2, the writeinstruction (200) that is associated with the read instruction (202) maynot yet have been issued at the time it was determined (208) that theread instruction (202) is associated with a write instruction (200) towrite data to a second memory drive (226) in the drive array (222). Thatis, the issuer of the read instruction (202) may know, at the time thatthe read instruction (202) is issued, that the read instruction (202) isjust one memory access request in a series of memory access requeststhat will involve issuing a write instruction (200) to write data to asecond memory drive (226) in the drive array (222) at a later time.

Consider the example described above in which the drive array (222) is aRAID 5 compliant array. In such an example, performing paritycalculations for the drive array (222) can include reading data from aplurality of memory drives (224, 228), using the data that was read fromthe memory drives (224, 228) as input to an exclusive OR operation, andsubsequently writing the result of the exclusive OR operation to anothermemory drive (226) that is responsible for maintaining parityinformation for a particular portion of the memory drives (224, 228). Insuch an example, a read instruction would be issued to memory drive(224) and another read instruction would be issued to memory drive(228). Each read instruction would be associated with a writeinstruction that will be issued to memory drive (226) upon thecompletion of the exclusive OR operation. As such, even though memorydrive (226) may not be actively servicing any memory access requests,the issuance of a read instruction to memory drive (224) and anotherread instruction to memory drive (228) as part of parity calculationswould serve as an indication that memory drive (226) will be servicing amemory access request—writing the result of the exclusive OR operationto the memory drive (226)—in the near future.

The example method of FIG. 2 also includes restricting (212), by thedrive array controller (204), performance of background managementoperations on the second memory drive (226) in the drive array (222). Inthe example method of FIG. 2, restricting (212) performance ofbackground management operations on the second memory drive (226) in thedrive array (222) is carried out in response to affirmatively (210)determining that the read instruction (202) is associated with the writeinstruction (200). In the example method of FIG. 2, backgroundmanagement operations can include data scrubbing operations, consistencychecking, and other management operations that are frequently run asbackground tasks to ensure proper operation of the memory drives (224,226, 228). A particular operation may be identified as being abackground management operation, for example, as part of configuring acomputing system, as the result of input from a system administrator,and so on. Such background operations are typically executed through theuse of a background process that is running in the background withoutuser intervention.

When a particular memory drive (224, 226, 228) is servicing memoryaccess requests that are performed as part of background managementoperations, the memory drive (224, 226, 228) will have less capacity toservice memory access requests that are performed as the result ofnormal computing operations. The memory drive (224, 226, 228) may haveless capacity to service memory access requests that are performed asthe result of normal computing operations because resources required toservice memory access requests that are performed as part of backgroundmanagement operations are being dedicated to the execution of thebackground management operations. As such, the performance of backgroundmanagement operations on the second memory drive (226) in the drivearray (222) may be restricted (212) in anticipation of servicing thewrite instruction (200) that is related to the read instruction (202).Restricting (212) the performance of background management operations onthe second memory drive (226) in the drive array (222) can include, forexample, limiting the percentage of memory access requests that thesecond memory drive (226) may service as part of performing backgroundmanagement operations to a predetermined threshold.

The example method of FIG. 2 also includes receiving (214), by the drivearray controller (204), the write instruction (200). In the examplemethod of FIG. 2, the write instruction (200) may be issued to the drivearray controller (204), for example, by a computer processor (not shown)over a memory bus. Such a write instruction (200) may be part of alarger memory management operation such as, for example, performingparity calculations for memory drives (224, 226, 228) in the drive array(222).

The example method of FIG. 2 also includes determining (216), by thedrive array controller (204), whether the write instruction (200) hascompleted. In the example method of FIG. 2, determining (216) whetherthe write instruction (200) has completed may be carried out, forexample, by inspecting each completed write instruction that the drivearray controller (204) causes to execute. In such an example, eachcompleted write instruction may be examined to determine whether theexecuted write instruction is the same write instruction (200) that isrelated to the read instruction (202). In order to determine whether aparticular executed write instruction is the same write instruction(200) that is related to the read instruction (202), the readinstruction (202) and the write instruction (200) may include metadatathat identifies the two instructions as being related. Such metadata mayinclude, for example, an identifier that includes a unique value that isincluded in metadata associated with the read instruction (202) and alsoincluded in metadata associated with the write instruction (202). Insuch an example, when the drive array controller (204) receives a readinstruction (202) that has a related write instruction (200), the drivearray controller (204) may store the unique identifier contained in theread instruction (202). This value may be compared against valuescontained in metadata associated with incoming write instructions toidentify the write instruction (202) that includes a matching uniqueidentifier.

Consider the example described above in which the drive array (222) is aRAID 5 compliant array. Performing parity calculations for the drivearray (222) can therefore include reading data from a plurality ofmemory drives (224, 228), using the data that was read from the memorydrives (224, 228) as input to an exclusive OR operation, andsubsequently writing the result of the exclusive OR operation to anothermemory drive (226) that is responsible for maintaining parityinformation for a particular portion of the memory drives (224, 228). Insuch an example, the read instruction that is issued to memory drive(224) and read instruction that is issued to memory drive (228) mayinclude metadata identifying these read instructions as being related toa write instruction that has not yet been issued. Each read instructioncan also include a particular value that is to be used as an identifierof the group of instructions. This value can be stored in memory used bythe drive array controller (204). When the drive array controller (204)subsequently receives an incoming write instruction, the drive arraycontroller (204) may examine the metadata associated with the incomingwrite instruction to determine whether the metadata associated with theincoming write instruction includes a value that matches the value thatwas that includes in the read instruction that is issued to memory drive(224) and read instruction that is issued to memory drive (228). If thevalues match, the incoming write instruction represents that relatedwrite instruction that was identified in the read instruction that isissued to memory drive (224) and read instruction that is issued tomemory drive (228). Once the related write instruction is executed,there is no longer a need to restrict the performance of backgroundmanagement operations on the memory drive (226) targeted by the writeoperation.

The example method of FIG. 2 also includes removing (220), by the drivearray controller (204), the restrictions associated with the performanceof background management operations on the second memory drive (226) inthe drive array (222). In the example method of FIG. 2, removing (220)the restrictions associated with the performance of backgroundmanagement operations on the second memory drive (226) in the drivearray (222) is carried out in response to affirmatively (218)determining that the write instruction (200) has completed. Removing(220) the restrictions associated with the performance of backgroundmanagement operations on the second memory drive (226) in the drivearray (222) may be carried out, for example, by removing any limitationsas to the percentage of memory access requests that the second memorydrive (226) may service as part of performing background managementoperations, by increasing the percentage of memory access requests thatthe second memory drive (226) may service as part of performingbackground management operations, and so on.

For further explanation, FIG. 3 sets forth a flow chart illustrating anadditional example method for limiting the execution of backgroundmanagement operations in a memory device according to embodiments of thepresent invention. The example method of FIG. 3 is similar to theexample method of FIG. 2, as it also includes receiving (206) a readinstruction (202) to read data from a first memory drive (224) in adrive array (222), determining (208) whether the read instruction (202)is associated with a write instruction (200) to write data to a secondmemory drive (226) in the drive array (222), restricting (212)performance of background management operations on the second memorydrive (226) in the drive array (222), receiving (214) the writeinstruction (200), determining (216) whether the write instruction (200)has completed, and removing (220) the restrictions associated with theperformance of background management operations on the second memorydrive (226) in the drive array (222).

In the example method of FIG. 3, the read instruction (202) includesmetadata (302) identifying whether the read instruction (302) is relatedto a write instruction (200) to write data to the second memory drive(226) in the drive array (222). The metadata (302) of FIG. 3 mayinclude, for example, a value indicating that the read instruction (302)has an associated dependent write instruction (200), an identifier witha value that identifies the related set of instructions such that thesame value will be included in metadata included in the dependent writeinstruction (200), and so on. In the example method of FIG. 3,determining (208) whether the read instruction (202) is associated witha write instruction (200) to write data to the memory device (222) cantherefore include examining (304), by the drive array controller (204),the metadata (302) identifying whether the read instruction (202) isrelated to a write instruction (200) to write data to the memory device(222).

In the example method of FIG. 3, restricting (212) performance ofbackground management operations on the memory device (222) includeslimiting (306), to a predetermined threshold, an amount of memoryaccesses requests from background management operations that may beserviced by the second memory drive (226). In the method of FIG. 3, thepredetermined threshold may be specified in terms of an amount of memoryaccesses requests from background management operations that the secondmemory drive (226) may service in a predetermined period of time, amaximum percentage of all memory accesses requests that are serviced bythe second memory drive (226) that can originate from backgroundmanagement operations, and so on. In the example method of FIG. 3, thedrive array controller (204) may simply ignore or reject any memoryaccess requests that are directed to the second memory drive (226) thatexceed the predetermined threshold. In such a way, the drive arraycontroller (204) may ensure that the second memory drive (226) is notservicing background management operations to an extent that will causean unnecessary delay in processing the write instruction (200).

In the example method of FIG. 3, the write instruction (200) includesmetadata (300) identifying a group of related instructions that includesthe write instruction (200). The metadata (300) of FIG. 3 may include,for example, a value indicating that the write instruction (300) is partof a group of instructions that includes one or more associated readinstructions (202) that the write instruction (300) is dependent upon,an identifier with a value that identifies a specific group of relatedinstructions such that the same value will be included in metadataincluded in the one or more related read instructions (202), and so on.

In the example method of FIG. 3, determining (216) whether the writeinstruction (200) has completed can include examining (308), by thedrive array controller (204), the metadata (300) identifying a group ofrelated instructions that includes the write instruction (200). In theexample method of FIG. 3, examining (308) the metadata (300) identifyinga group of related instructions that includes the write instruction(200) may be carried out, for example, by inspecting each completedwrite instruction that the drive array controller (204) causes toexecute. In such an example, each completed write instruction may beexamined (308) to determine whether the write instruction (200) is partof a group of related instructions that includes the read instruction(202). In order to determine the write instruction (200) is part of agroup of related instructions that includes the read instruction (202),the metadata (300) contained in the write instruction (200) may becompared to the metadata (302) contained in the read instruction (202)to identify a match. In such an example, when the drive array controller(204) receives a read instruction (202) that has a related writeinstruction (200), the drive array controller (204) may store the uniqueidentifier contained in the read instruction (202). This value may becompared against values contained in metadata associated with incomingwrite instructions to identify the write instruction (202) that includesa matching unique identifier.

Although the examples described above describe embodiments in which datais read from a first memory drive and written to a second memory drive,readers will appreciate data may be read from and written to the samememory drive according to embodiments of the present invention. Thedescription of embodiments in which data is read from a first memorydrive and written to a second memory drive is included for ease ofexplanation and should not be read to limit the scope of the presentclaims.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described above with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

It will be understood from the foregoing description that modificationsand changes may be made in various embodiments of the present inventionwithout departing from its true spirit. The descriptions in thisspecification are for purposes of illustration only and are not to beconstrued in a limiting sense. The scope of the present invention islimited only by the language of the following claims.

1-6. (canceled)
 7. An apparatus for limiting the execution of backgroundmanagement operations in a drive array, the apparatus comprising acomputer processor, a computer memory operatively coupled to thecomputer processor, the computer memory having disposed within itcomputer program instructions that, when executed, cause the apparatusto carry out the steps of: receiving, by a drive array controller, aread instruction to read data from a memory drive in the drive array;determining, by the drive array controller, whether the read instructionis associated with a write instruction to write data to a memory drivein the drive array; responsive to determining, by the drive arraycontroller, that the read instruction is associated with the writeinstruction, restricting, by the drive array controller, performance ofbackground management operations on the memory drive targeted by thewrite instruction; determining, by the drive array controller, whetherthe write instruction has completed; and responsive to determining, bythe drive array controller, that the write instruction has completed,removing, by the drive array controller, restrictions associated withthe performance of background management operations on the memory drivetargeted by the write instruction.
 8. The apparatus of claim 7 whereinthe read instruction includes metadata identifying whether the readinstruction is related to the write instruction.
 9. The apparatus ofclaim 8 wherein determining whether the read instruction is associatedwith the write instruction includes examining, by the drive arraycontroller, the metadata identifying whether the read instruction isrelated to the write instruction.
 10. The apparatus of claim 7 whereinthe write instruction includes metadata identifying a group of relatedinstructions that includes the write instruction.
 11. The apparatus ofclaim 10 wherein determining whether the write instruction has completedincludes examining, by the drive array controller, the metadataidentifying a group of related instructions that includes the writeinstruction.
 12. The apparatus of claim 7 wherein restrictingperformance of background management operations on the memory drivetargeted by the write instruction includes limiting, to a predeterminedthreshold, an amount of memory accesses requests from backgroundmanagement operations that may be serviced by the memory drive targetedby the write instruction.
 13. A computer program product for limitingthe execution of background management operations in a drive array, thecomputer program product disposed upon a computer readable medium, thecomputer program product comprising computer program instructions that,when executed, cause a computer to carry out the steps of: receiving, bya drive array controller, a read instruction to read data from a memorydrive in the drive array; determining, by the drive array controller,whether the read instruction is associated with a write instruction towrite data to a memory drive in the drive array; responsive todetermining, by the drive array controller, that the read instruction isassociated with the write instruction, restricting, by the drive arraycontroller, performance of background management operations on thememory drive targeted by the write instruction; determining, by thedrive array controller, whether the write instruction has completed; andresponsive to determining, by the drive array controller, that the writeinstruction has completed, removing, by the drive array controller,restrictions associated with the performance of background managementoperations on the memory drive targeted by the write instruction. 14.The computer program product of claim 13 wherein the read instructionincludes metadata identifying whether the read instruction is related tothe write instruction.
 15. The computer program product of claim 14wherein determining whether the read instruction is associated with thewrite instruction includes examining, by the drive array controller, themetadata identifying whether the read instruction is related to thewrite instruction.
 16. The computer program product of claim 13 whereinthe write instruction includes metadata identifying a group of relatedinstructions that includes the write instruction.
 17. The computerprogram product of claim 16 wherein determining whether the writeinstruction has completed includes examining, by the drive arraycontroller, the metadata identifying a group of related instructionsthat includes the write instruction.
 18. The computer program product ofclaim 13 wherein restricting performance of background managementoperations on the memory drive targeted by the write instructionincludes limiting, to a predetermined threshold, an amount of memoryaccesses requests from background management operations that may beserviced by the memory drive targeted by the write instruction.
 19. Thecomputer program product of claim 13 wherein the computer readablemedium comprises a signal medium.
 20. The computer program product ofclaim 13 wherein the computer readable medium comprises a storagemedium.